home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000531_fine@cis.ohio-state.edu _Fri Jan 8 21:37:21 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <fine@cis.ohio-state.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA02377; Fri, 8 Jan 93 21:37:21 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA03551; Fri, 8 Jan 1993 21:52:21 +0100
  6. Received: by soccer.cis.ohio-state.edu (5.61-kk/5.911008)
  7.     id AA14305; Fri, 8 Jan 93 15:52:19 -0500
  8. Date: Fri, 8 Jan 93 15:52:19 -0500
  9. From: Thomas A. Fine <fine@cis.ohio-state.edu>
  10. Message-Id: <9301082052.AA14305@soccer.cis.ohio-state.edu>
  11. To: connolly@pixel.convex.com, timbl@nxoc01.cern.ch
  12. Subject: Re: dealing with new-lines 
  13. Cc: www-talk@nxoc01.cern.ch
  14. X-Mailer: Perl Mail System v1.1
  15.  
  16. >> Beacuse
  17. >>each XMP section is like a black box, any white spce inside it would not be  
  18. >>seen by the white space management logic which overlaps the white spaces  
  19. >>required around successive paragraphs, and extra white spce would result.
  20. >
  21. >Unfortunately, this conflicts with the SGML standard. An SGML parser
  22. >will report
  23. ><XMP>
  24. >foo
  25. ></XMP>
  26. >
  27. >as
  28. >an XMP start tag
  29. >the string "foo" [NOT "\nfoo\n"]
  30. >an XMP end tag
  31. >
  32. >And so it is, strictly speaking, illegal to treat the above markup
  33. >differently from
  34. ><XMP>foo</XMP>
  35. >
  36. >I'm not sure how we should resolve this.
  37.  
  38. This was almost the exact example I was playing with when I decided to start
  39. this messy discussion.  Also some paragraph examples.  Both of the following
  40. should mean the same:
  41.  
  42. some text<P>more text
  43.  
  44. and
  45.  
  46. some text
  47. <P>
  48. more text
  49.  
  50. The latter being commonly used.  I realized that unless you could remove
  51. surround new-lines in cases like this, the second paragraph would start
  52. with a space.  Similarly, you might find headings, or other things with
  53. a space at the beginning.
  54.  
  55. >>    PRE
  56. >>
  57. >>By the way, I think we agreed (I gave in) that the <PRE> sections would have
  58. >>siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which
  59. >>gives double spacing on my browsers.  So I tread newlines as newlines in all
  60. >>the <PRE> element just as XMP.
  61. >
  62. >This is a situation we need to resolve, one way or another. I'm inclined
  63. >to decide that <p> elements are allowed in PRE elements, but they have
  64. >no significance. They were put there to cause the old linemode browser
  65. >to break the line, so they have always been redundant. So Tim's treatment
  66. >of newlines in PRE is correct, but his treatment of <P> there is not
  67. >[by this new convention.]
  68.  
  69. Note that the method I proposed has the advantage of automatically dealing
  70. with this (sort of).  If the document was converted simply by adding a <P>
  71. to the end of each line, then for such lines, I remove the newline but keep
  72. the <P>.  Then the code that deals with PRE sections can happily honor
  73. both new-lines and <P> tags, thus making it compatible with either style.
  74.  
  75.     tom